Generally, a Graphical User Interface (GUI) is a software application that interacts with a user via a display device. The GUI may receive input from the user through different input devices, such as a mouse and pointer combination, or a keyboard. FIG. 1 shows a GUI output displayed on a computer monitor screen. The GUI output includes widgets that allow the user to interact with the GUI. Widgets are items such as windows, captions, buttons, labels, menu bars, toolbars, dialog boxes, menus, icons, etc. For example, a window (12) may have a menu bar (16). Further, there are two menus in the menu bar (16), an Edit menu (18) and a File menu (20). Additionally, widgets may represent software applications that are available to be executed by the user, such as a Web Browser widget (22).
When the user interacts with the GUI by, for example, clicking a mouse button while the pointer is positioned above a widget, an event is sent from the mouse to the GUI. The event is a signal transmitted by a computer on which the GUI is executing, and is directed to the GUI. The event may be relayed from the mouse to the GUI by means of a communications framework, e.g., an operating system, a virtual machine, a windowing toolkit, etc. The GUI interprets the event and generates a response based on the position of the pointer when the mouse was clicked. For example, if the user clicks on the File menu (20), an event is sent from the mouse to the GUI, to access the File menu (20) item. The GUI receives the event, interprets the event, and determines that the user wants the File menu (20) to be expanded, and the GUI then alters the graphical interface to reflect the expansion of the File menu (20). The altered graphical interface with the expanded File menu (20) is shown in FIG. 2. The expanded File menu (20) includes an Open item (26) and a Close item (28).
As shown in FIG. 3, an event queue (40) receives events from one or more input devices (42) via an event queue input link (43). The input device(s) (42) places an event into the event queue (40) at an event queue tail (48), and the event is released from an event queue (40) via an event queue head (50) and sent to the GUI (44) via a GUI event input link (51). The GUI (44) may send self-events to the event queue (40) via the event queue input link (43). Self-events may be sent from a GUI to an event queue in the course of normal operations. For example, referring to FIG. 1, in the course of drawing a dialog box, a GUI may send self-events to an event queue. A communications framework (54) provides the ability for the entities depicted in FIG. 3 to communicate.
In order to test a GUI during development, test events may be sent from a GUI Test Tool to a GUI. As shown in FIG. 4, a GUI Test Tool (60) is a software application that may be used to perform a test of a GUI (44) in order to detect errors in the design, construction, and operation, etc., of the GUI (44). In order to test the GUI (44), the GUI Test Tool (60) typically operates in conjunction with a test suite (62), a reference file (64), and a communications framework (54). The test suite (62) is a document that is a collection of one or more tests used to determine whether the GUI (44) is functioning as specified. A test typically contains one or more test events to be sent to the GUI (44) during testing. The test events are designed to exercise one or more features of the GUI (44) by simulating user input. For example, the test event “SelectMenuItem (FileMenu)” simulates a user selecting the File menu. A test (66) from the test suite (62) is read into the GUI Test Tool (60), which subsequently generates a corresponding test event (68). The test event (68) is then sent to the GUI (44). The GUI (44) generates a response (70) to the test event (68), and the GUI Test Tool (60) acquires and evaluates the response (70) to determine whether the response (70) is proper. In order to determine whether the response (70) is proper, the GUI Test Tool (60) may refer to a reference file (64) that includes a proper response for particular test events. The GUI Test Tool (60) may compare the proper response with a post-response widget hierarchy (i.e., a system mapping of the hierarchy of the widgets within a graphical interface) of the GUI (44). Alternatively, the GUI Test Tool (60) may use other means, such as bitmap comparisons, in order to determine whether the response (70) is proper. Typically, proper responses are gathered prior to testing and stored in the reference file (64) for future use, i.e., GUI testing during development.
In the course of testing a GUI, test events may be sent from a GUI Test Tool to a GUI via various mechanisms. In certain circumstances, test events sent to a GUI from a GUI Testing Tool, may be sent to individual widgets associated with the GUI. Commonly, this approach increases probability of generating errors during the GUI testing. For example, a GUI Testing Tool may send a first test event to cause a File menu to expand. The expanded File menu (20) is shown in FIG. 2. Accessing the Open item (26) within the expanded File menu (20) causes a dialog box (not shown) to appear. In order to access the Open item (26), the GUI Test Tool may send a second test event to the Open item (26). However, if, when the second test event is sent to the Open item (26), the first test event has not been completed by the GUI, the second test event may produce an error. The error is caused by sending the second test event to Open item (26), which had not yet been fully drawn.
FIG. 5 shows a time sequence involving an event directed to a GUI. The timeline (73) proceeds chronologically from left to right. A first event (74), at time T1 (75), may be, for example, a test event directed to a File menu. A second event (76), at time T2 (77), a third event (78), at time T3 (79), and a fourth event (80), at time T4 (81), are subsidiary events, sent from the GUI to an event after the GUI has received an event. In this example, subsidiary events, i.e., second event (76), third event (78), etc., are self events that may be sent from a GUI to an event queue at regular chronological intervals while a test event is being processed.
Referring to the foregoing example, until the File menu is fully drawn (expanded), the GUI may send subsidiary events at regular chronological intervals to the event queue. The amount of time needed for a GUI to complete processing a test event may vary due to system loading or other factors. When the File menu is fully expanded, the GUI may stop sending subsidiary events to the event queue. Subsidiary event intervals (e.g., the time period between T2 (77) and T3 (79)) may vary according to the particular GUI and/or the particular event that precipitates the subsidiary events. Furthermore, the GUI may also send subsidiary events to the event queue at irregular chronological intervals. Additionally, events, such as system calls, may be sent to the event queue by the communications framework or from other software applications.